This PR will not go through. Please rework:

1. changes in statescontroller.js

• blocking the call should not occur before the debug message is sent
• the check for !entity || !entity.device makes no sense. Possible options are (!entity) or !(entity?.device) (ResolveEntity either returns a structure with the property device or undefined )

2. changes in zigbeecontroller.js

• encapsulating the entire function in a try/catch is the blunt approach, and quite unnecessary. Note that all functions called are either explicitly safeguarding, secured via try/catch, or called via 'emit' (which breaks the try/catch)
• fix the 'improper' use of || when addressing complex structures (i.e. data.device || data.ieeeAddr => data.device ?? data.ieeeAddr
• fix the improper use of _modelID (an internal property which should never be addressed directly, as it may no longer be available in the future)
• Implement guarding against data being undefined (by addressing its properties via data?.

Alternatively, this will return onto the stack of planned reworks and be done when I get to it.

A.

Reworked:

1. statescontroller.js — the debug message now goes out before the guard; the guard is reduced to if (!entity) return (resolveEntity returns a { device, … } structure or undefined, so checking .device separately was redundant).

2. zigbeecontroller.js handleMessage — dropped the wrapping try/catch. Checked the callees first: resolveEntity has its own try/catch and returns undefined on failure, callExtensionMethod guards each extension call, and event() dispatches via emit (its handlers are outside the try/catch regardless). What remained was the synchronous access on data, now guarded directly.

3. data.device || data.ieeeAddr -> data.device ?? data.ieeeAddr

4. Dropped _modelID — besides being internal it's never actually set on a resolveEntity result, so the log name always fell through to the ieeeAddr. Using entity?.name now (the name resolveEntity already builds via selectName / Coordinator / Group). Say if you'd prefer the raw modelID instead.

5. data is addressed via data?. throughout handleMessage.

One related line in utils.js: entityData() had name: e.name while every other field there (and every helper it calls) already used optional chaining, so entityData(undefined) threw on that single line. Since (1) now lets the debug run with an unresolved entity, I made that field e?.name as well — otherwise the reorder would just move the original crash into debug mode.

Thanks.